Method and system for remote automation of object oriented applications

ABSTRACT

An object oriented programming environment is extended to allow a client object oriented application running under a client/server operating system to communicate with a plurality of server object oriented applications located on one or more remote computers in a distributed computer environment. The extended object oriented programming environment provides the capability for a client object oriented application to connect to, and communicate with remote server object oriented applications as well as make object references to remote objects and remote object data. The extended object oriented programming environment is used for designing N-tiered logical models for distributed computing applications, while providing a flexible and adaptable M-tiered physical model underneath the N-tiered logical model. This environment is also used to provide the ability to reference remote objects from Internet and other client network applications.

CROSS REFERENCE TO RELATED APPLICATION

This is a continuation of U.S. patent application Ser. No. 09/114,227,filed Jun. 30, 1998, now U.S. Pat. No. 6,820,267 which is a divisionalof U.S. Pat. No. 5,881,230, entitled, “METHOD AND SYSTEM FOR REMOTEAUTOMATION OF OBJECT ORIENTED APPLICATIONS,” issued Mar. 9, 1999.

FIELD OF INVENTION

The present invention relates to communications between client/serverobject oriented applications. More particularly it relates to thecommunication of object oriented information between a client objectoriented application and a server object oriented application running ona remote computer in a distributed computing environment.

BACKGROUND AND SUMMARY OF THE INVENTION

Object oriented programming, as is well known in the art, is used todesign computer software that is easy to create, cost effective tomodify, and reusable. Object oriented software provides dataabstraction, which hides the physical representation of data withinobjects, and thus lessens the impact of changes when modifications aremade to the software.

The Component Object Model (COM) for object oriented programmingspecifies how objects within a single application or betweenapplications (e.g. client/server applications) interact and communicateby defining a set of standard interfaces. Interfaces are groupings ofsemantically related functions through which a client applicationaccesses the services of a server application.

Object Linking and Embedding (OLE), such as OLE Version 2 by MicrosoftCorporation of Redmond, Wash., is based in part on the Component ObjectModel and allows the creation of objects of different formats whichoperate on object data through defined interfaces, rather than on theapplications responsible for the data. Using OLE, object data can beembedded within an object, or linked to it, so that only a reference tothe object data is stored in the object. OLE enables developers tocreate sophisticated and extensible client/server applications.

At the heart of the OLE object system is the ability for a client objectoriented application to have a reference to an object in a server objectapplication, even though the two applications are not sharing computerprocess memory (e.g., computer memory, in the same operating systemprocess space). In many client/server systems, both the client andserver application exist within the same operating system process, andthus are able to share process memory. To allow an out-of-shared memoryreference, two additional objects are created to maintain the objectreference: an OLE proxy object in the client application, and an OLEstub object in the server application. An OLE channel is also createdthat connects the OLE proxy and stub objects. To the client, the OLEproxy object looks and acts just like the real object, because the OLEproxy intercepts and forwards all calls to the real object through theOLE channel to the OLE stub object. The OLE stub object in turn callsthe real object. The communication between the OLE proxy and OLE stub ismanaged by an OLE channel object, which sends information between theclient and server processes.

There are several problems associated with the existing OLE proxy/OLEchannel/OLE stub model to maintain an object reference for client/serverobject applications that do not share memory. The OLE channel is notcapable of sending information between client and server processes ondifferent computers. In a distributed computing environment, client andserver applications are typically located on different computers;therefore a client application cannot contain an object reference to aserver application running on a remote computer. There is also no way tomaintain object identity if an object reference was passed from a clientobject application to a remote server object application on a remotecomputer since object references are not known outside the localcomputer. This limits the ability of software developers to writedistributed object applications using existing OLE and other objectoriented frameworks.

The OLE proxy/OLE channel/OLE stub model also limits the ability ofdevelopers to create anything more than traditional two-tierclient/server applications. If a client application could containreferences to more than one remote server application (i.e., on one ormore remote computers), then three-tier, four-tier, and potentiallyN-tier client/server layering could be accomplished. Three-tierclient/server object layering is desirable for many businessapplications (e.g., a first tier providing user services, a remotesecond tier providing business services, and a remote third tierproviding data services).

The inability to reference a remote object also limits the scope of anetwork client object application (e.g., an Internet objectapplication), as only objects on the same computer can currently bereferenced. The ability to reference a remote object (e.g., from ahypertext markup language (HTML) file, or in a HTML universal resourcelocator (URL)) would greatly enhance the variety and format ofinformation (i.e. including audio, video, etc.) that could be accessedby a client network object application.

In accordance with the present invention, the ability to referenceremote server object oriented applications on remote computers isachieved. The present invention provides a method for remote automationof object oriented applications. The remote automation method includesproviding a two-way communications path between a client object orientedapplication on a client computer and one or more server object orientedapplications residing on one or more remote computers, where the two-waycommunications path includes an object linking and embedding channel.The object linking and embedding channel allows object linking andembedding information (e.g., OLE information) to be sent to a remotecomputer. An object reference that is uniquely represented andidentifiable by both the client object oriented application and themultiple server object oriented applications is accepted from the clientobject oriented application. The accepted object reference is passedover the two-way communications path using the object linking andembedding channel to the remote server object oriented application. Theobject linking and embedding channel allows object linking and embeddinginformation to be sent to a remote computer with the minimum datamanipulation or conversion. The remote object is returned to the clientobject oriented application from a selected server object orientedapplication.

Using the remote automation method, a client object oriented applicationcan reference remote objects and remote object data on server objectoriented applications running on one or more remote computers, providedthe client and server computers are connected by a compatible computernetwork. The remote automation method provides multiple networkconnection possibilities including TCP/IP, PPP, and SLIP to connect theclient and server computers.

The remote automation method is used to extend the OLE object creationprocess and modify OLE object data. Since only OLE object data ismodified, the remote automation method is compatible with existing andpreviously written OLE client and server object oriented applications,and can be used without modifying these existing applications. Inaddition, the remote automation method maintains the identity of anobject as an object reference is passed to one or more remote computersusing the remote automation method.

With the remote automation method, an N-tiered client/server objectapplication model is possible. In addition, object references to remoteobjects can now be added to network object applications (e.g., in HTMLor HTML URLs), greatly enhancing the variety and format of informationavailable to network object applications.

The remote automation method allows developers to quickly and cleanlycreate distributed client/server object applications, using a known andfamiliar object oriented programming environment (i.e., OLE), whichdecreases development time, and lowers overall development costs.

The foregoing and other features and advantages of the present inventionwill be more readily apparent from the following detailed description,which proceeds with reference to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a computer system used to implement apreferred embodiment of the present invention.

FIG. 2 is a flow diagram of a method for one embodiment of the presentinvention.

FIG. 3 is a block diagram illustrating the existing OLE object orientedcommunication between a client and server object oriented application onthe same computer.

FIG. 4 is a block diagram illustrating remote OLE object orientedcommunications between a client object oriented application and a remoteserver object oriented application on a remote computer.

FIG. 5 is a block diagram illustrating the facelet/stublet interactionbetween a proxy and remote stub.

FIG. 6 is a block diagram illustrating one example of a logicalthree-tiered services model.

FIG. 7A is a block diagram illustrating one physical embodiment of thelogical three-tiered services model shown in FIG. 6.

FIG. 7B is a block diagram illustrating a second physical embodiment ofthe logical three-tiered services model shown in FIG. 6.

FIG. 8 is a flow chart illustrating a method for one embodiment of thepresent invention.

FIG. 9 is a flow chart illustrating N-tier layering for one embodimentof the present invention.

DETAILS DESCRIPTION OF PREFERRED EMBODIMENT

Referring to FIG. 1, an operating environment for the preferredembodiment of the present invention is a computer system 10 with acomputer 12 that comprises at least one high speed processing unit (CPU)14, in conjunction with a memory system 16, an input device 18, and anoutput device 20. These elements are interconnected by a bus structure22.

The illustrated CPU 14 is of familiar design and includes an ALU 24 forperforming computations, a collection of registers 26 for temporarystorage of data and instructions, and a control unit 28 for controllingoperation of the system 10. Any of a variety of processors, includingthose from Digital Equipment, Sun, MIPS, IBM, Motorola, NEC, Intel,Cyrix, AMD, Nexgen and others are equally preferred for CPU 14. Althoughshown with one CPU 14, computer system 10 may alternatively includemultiple processing units.

The memory system 16 includes main memory 30 and secondary storage 32.Illustrated main memory 30 is high speed random access memory (RAM) andread only memory (ROM). Main memory 30 can include any additional oralternative high speed memory device or memory circuitry. Secondarystorage 32 takes the form of long term storage, such as ROM, optical ormagnetic disks, organic memory or any other volatile or non-volatilemass storage system. Those skilled in the art will recognize that memory16 can comprise a variety and/or combination of alternative components.

The input and output devices 18, 20 are also familiar. The input device18 can comprise a keyboard, mouse, pointing device, audio device (e.g. amicrophone, etc.), or any other device providing input to the computersystem 10. The output device 20 can comprise a display, a printer, anaudio device (e.g. a speaker, etc.), or other device providing output tothe computer system 10. The input/output devices 18, 20 can also includenetwork connections, modems, or other devices used for communicationswith other computer systems or devices.

As is familiar to those skilled in the art, the computer system 10further includes an operating system and at least one applicationprogram. The operating system is a set of software which controls thecomputer system's operation and the allocation of resources. Theapplication program is a set of software that performs a task desired bythe user, making use of computer resources made available through theoperating system. Both are resident in the illustrated memory system 16.

In accordance with the practices of persons skilled in the art ofcomputer programming, the present invention is described below withreference to acts and symbolic representations of operations that areperformed by computer system 10, unless indicated otherwise. Such actsand operations are sometimes referred to as being computer-executed. Itwill be appreciated that the acts and symbolically representedoperations include the manipulation by the CPU 14 of electrical signalsrepresenting data bits which causes a resulting transformation orreduction of the electrical signal representation, and the maintenanceof data bits at memory locations in memory system 16 to therebyreconfigure or otherwise alter the computer system's operation, as wellas other processing of signals. The memory locations where data bits aremaintained are physical locations that have particular electrical,magnetic, optical, or organic properties corresponding to the data bits.

The data bits may also be maintained on a computer readable mediumincluding magnetic disks, and any other volatile or non-volatile massstorage system readable by the computer 12. The computer readable mediumincludes cooperating or interconnected computer readable media, whichexist exclusively on computer system 10 or are distributed amongmultiple interconnected computer systems 10 that may be local or remote.

In a preferred embodiment of the present invention, the computer system10 preferably uses the Windows® 95 client/server operating system.However, other client/server operating systems (e.g. Windows NT™, OS/2®,by IBM, etc.) could also be used. A client/server operating system is anoperating system which is divided into a plurality of processes of twodifferent types: server processes, each of which typically implements asingle set of services, and client processes, which request a variety ofservices from the server processes. Object oriented programming is usedto design the client/server operating system, where objects representsystem resources.

For example, the Windows® 95 client/server operating system providesshareable resources, such as files, memory, processes and threads, whichare implemented as “objects” and are accessed by using “objectservices.” As is well known in the art, an “object” is a data structurewhose physical format is hidden behind a type definition. Datastructures, also referred to as records or formats, are organizationschemes applied to data so that it can be interpreted, and so thatspecific operations can be performed on that data. Such data structuresimpose a physical organization on the collection of data stored withincomputer memory 16 and represent specific electrical, magnetic ororganic elements.

An “object type,” also called an “object class,” comprises a data-type,services that operate on instances of the data type, and a set of objectattributes. An “object attribute” is a field of data in an object thatpartially defines that object's state. An “object service” implementsand manipulates objects, usually by reading or changing the objectattributes. “Object oriented design” is a software development techniquein which a system or component is expressed using objects.

An object typically has two components: a function table, containing apointer to each object member function (i.e. sometimes known as anobject method) defined in the object's class, and a data block,containing the current values for each object variable (i.e., datamembers, sometimes known as an object property). An application has somereference to an object through an object pointer. An application obtainsthis object reference by using some type of function call (direct orimplied) in which that function allocates an object block in computermemory, initializes the function table, and returns the reference to thecomputer memory to an application. The computer memory may be local ordistributed on a remote computer.

The Windows® 95 operating system allows users to execute more than oneprogram at a time by organizing the many tasks that it must perform into“processes.” The operating system allocates a portion of the computer'sresources to each process and ensures that each process's program isdispatched for execution at the appropriate time and in the appropriateorder.

In one embodiment of the present invention, processes are implemented asobjects. A process object comprises the following elements: anexecutable program; a private address space; system resources (e.g.,communication ports and files) that the operating system allocates tothe process as the program executes; and at least one “thread ofexecution.” A “thread” is the entity within a process that the operatingsystem kernel schedules for execution. As is well known in the art, eachthread has an associated “context” which is the volatile data associatedwith the execution of the thread. A thread's context includes thecontents of system registers and the virtual address belonging to thethread's process. Thus, the actual data comprising a thread's contextvaries as it executes.

The Component Object Model (COM) is a model used for object orientedprogramming. The COM specifies how objects within a single applicationor between applications (e.g. client/server applications) interact andcommunicate by defining a set of standard interfaces. Interfaces aregroupings of semantically related functions through which a clientapplication accesses the services of a server application.

Object Linking and Embedding (OLE), such as OLE Version 2 by theMicrosoft Corporation of Redmond, Wash., is based in part on theComponent Object Model and allows the creation of objects of differentformats which operate on data through defined interfaces, rather thanoperating on the applications responsible for the data. The object datacan be embedded within an object, or linked to it, so that only a linkreference to the data is stored in the object.

FIG. 2 shows a method 34 for remote automation of object orientedapplications according to a preferred embodiment of the presentinvention. Method 34 allows a client object oriented application to makeremote object references, such as object linking and embeddedreferences, to multiple server object oriented applications over atwo-way communications path, where the two-way communications pathincludes an object linking and embedding channel. The remote objectreferences are used to obtain remote object and remote object data.

As is shown in FIG. 2, the remote automation method 34 includesproviding a two-way communications path between a client object orientedapplication on a client computer and one or more server object orientedapplications residing on one or more remote computers 36, where thetwo-way communications path includes an object linking and embeddingchannel. A remote object reference that is uniquely represented andidentifiable by both the client object oriented application and themultiple server object oriented applications is accepted from the clientobject oriented application 38. The accepted remote object reference ispassed over the two-way communications path using the object linking andembedding channel to the server object oriented application 40. Theremote object is returned to the client object oriented application fromthe server object oriented application over the object linking andembedding channel 42.

As is shown in FIG. 3, the existing OLE object system provides theability for a client object oriented application 44 (hereinafter clientapplication) to have a reference 46 to an object 48 in a server objectoriented application 50 (hereinafter server application) executing onthe same computer 10, even though the two applications are not sharingprocess memory. In many client/server operating systems, client andserver applications are confined to a single operating system processwhich allows the client and server application to communicate usingshared process memory. In Windows® 95 by Microsoft, and otherclient/server operating systems, client and server applications arecreated in separate processes, which typically do not share the samememory space, or use shared memory to communicate.

To allow out-of-shared memory references, two additional objects arecreated by OLE to maintain the object reference: an OLE proxy object 52in the client application 44, and an OLE stub object 54 in the serverapplication 50. An OLE channel 56 is also created which connects the OLEproxy and stub objects (52, 54).

When the object reference X->FOO( ) 46 is made on the client application44, the OLE proxy object 52 is treated internally just like the realobject X::FOO( ) 48, because the OLE proxy object 52 intercepts andforwards all calls to the real object through the OLE channel 56 to theOLE stub object 54. The OLE stub object 54 in turn calls the real object48. The communication between the proxy and stub is managed by an OLEchannel object 56, which understands how to send object informationbetween the client 44 and server 50 applications. The OLE objectreference support just described is typically used from a high levelobject oriented programming language. For example, the Visual Basic®programming language by Microsoft provides the support for the OLEclient/server proxy/stub object reference scheme described above.

The OLE proxy/stub object reference scheme only works for client andserver application executing on the same computer, which is a severelimitation. In a distributed computing environment, it is typical tohave a client application executing on one computer and serverapplication executing on another, remote computer.

In one embodiment of the present invention, the OLE environment ismodified and enhanced to allow object references to objects on remotecomputers. An object oriented application called Remote Automation (RA)is provided that works as an extension of, and in conjunction, with OLE.The Remote Automation object oriented application uses the remoteautomation method 34 to allow a server object oriented application tomake a remote object reference to a remote object or remote object dataon a server object oriented application.

The Remote Automation application extends the OLE object creationprocess by modifying the system registry data on the client computer.Since only OLE data is modified, Remote Automation is compatible withexisting OLE automation client/server applications. Existing OLEapplications do not have to be changed or recompiled using RemoteAutomation. On each host client/server operating system, preferably theoperating system registry (also called the registration database) isused to store relevant information about object components according totheir CLass IDentifier (CLSID). An object registers its CLSID in theoperating system registry to enable client applications to locate andload the executable code associated with the objects.

The CLSIDs are given the alias “GUID,” which stands for Globally UniqueIDentifiers. Each object class is represented by a GUID, a 128-bit(16-byte) number that is assumed to be unique in the world across spaceand time. A GUID is a 16-byte value with a specific structuraldefinition that has an ASCII representation shown below as a group ofhexadecimal digits within braces such as“{42754850-16b7-11ce-90eb-00aa003d7352}” (The groupings of the hexdigits and the hyphens are part of the ASCII representation as well).The structural definition of a GUID is manipulated by applicationsprograms such as the Remote Automation object oriented application.

The structural definition in C/C++ programming syntax of a GUID for theWindows® 95 operating is included in the Windows header file “wtypes.h”is shown below.

typedef struct _GUID {   DWORD Data1;   WORD Data2;   WORD Data3;   BYTEData4[8]; }  GUID;

where “DWORD Data1” is a double word sized variable “Data1”, “WORDData2” and “WORD Data3” are single word sized variables,and “BYTEData4[8]” is an array of eight one-byte (8-bit)variables.

When a client application 44 asks OLE to create an object, OLE mustfirst determine which server application to run. This information isstored in the operating system registry (e.g., Windows® 95 registry) foreach object class, and each object class is represented by a uniqueGUID. Most of the OLE object application information is stored insubkeys under the CLSID root key. For example, in Windows® 95, theoperating system registry may appear as follows:

CLSID // root key   {42754850-16b7-11ce-90eb-00aa003d7352} // GUIDsubkey     LocalServer32 = myserver.exe // local (same machine) server;where “{42754850-16b7-11ce-9eb-00aa003d7352}” is the ASCIIrepresentation of the GUID for the object class, and “LocalServer32”represents the registry sub-key name of the local server executable(e.g., myserver.exe) for the object class represented by the GUID.

In order for Remote Automation to function, the Remote Automationapplication is invoked during the OLE object creation process. This isdone by modifying the registry data in the operating system registry sothat OLE still loads a server application, but it is in fact loading aRemote Automation Proxy application which will communicate with theserver application. The “LocalServer32” registry sub-key is replacedwith a sub-key that tells OLE to load the Remote Automation proxy. Forexample, the modified operating system registry may appear as followsafter modification by Remote Automation:

CLSID // root key   {42754850-16b7-11ce-90eb-00aa003d7352} // GUIDsubkey     InProcServer32 = autprx32.dll // local (same machine) proxy;where “{42754850-16b7-11ce-90eb-00aa003d7352}” is the ASCII GUID for theclass, and “InProcServer32” represent the name of the registry sub-keyof the executable proxy for the object class represented by the GUID.However, in this example, the executable application is in autprx32.dll(i.e., AUTomation PRoXy Dynamic Link Library (DLL)). Dynamic linklibraries, as is known in the art, provide functions that applicationprograms link to and call as regular procedure calls. The“InProcServer32” keyword is used instead of the “LocalServer32” keywordsince the Remote Automation proxy application (in autprx32.dll) is anin-process object (i.e., operates within the same process as the clientobject application), while myserver.exe is an out-of-process objectapplication (i.e., operates within a process different from the clientobject application). The in-process Remote Automation proxy applicationwill communicate with a remote server application.

As long as the Remote Automation proxy object created by autprx32.dllforwards all requests to the real object in myserver.exe running on theremote computer, it does not matter that the real object does not existon the same computer as the client object application which made theobject reference.

When creating the real object, the Remote Automation application must beable to identify which remote computer to ask to create the real object.As a result, the Remote Automation application adds additional sub-keysto specify the network location (address) and the network protocol to beused to find and connect to the remote computer. For example, themodified operating system registry may now appear as follows:

CLSID // root key   {42754850-16b7-11ce-90eb-00aa003d7352}  // GUIDsubkey     InProcServer32 = autprx32.dll // local (same machine) proxy;    NetworkAddress = 1.24.128.36 // remote IP address    ProtocolSequence = ncanc_ip_tcp // tcp/ip connect protocolwhere the “NetworkAddress” sub-key in this example which specifies an IPaddress (e.g., 1.24.128.36) of a remote computer, and the“ProtocolSequence” specifies TCP/IP as the protocol that should be usedto connect to the remote computer. However, any number of differentnetwork address formats and connection protocols could also be specifiedin the NetworkAddress and ProtocolSequence sub-keys.

As is shown in FIG. 4, and is illustrated by method 134 in the flowchart in FIG. 8, a client object oriented application 58 on a clientcomputer 60 makes a remote referenc X->FOO( ) 62 process block 136) to aremote object X::FOO( )64 which resides on a remote server computer 66,and OLE on the client computer 60 (i.e., local OLE) consults themodified operating system registry 67 to determine which serverapplication to run.

Using the modified operating system registry shown below, and assumingthe ASCII GUID for the object class X::FOO( ) is{42754850-16b7-11ce-90eb-00aa003d7352}, local OLE finds this entry inthe modified operating system registry, and invokes autprx32.dll tocreate a RA proxy object application 68 (hereinafter RA proxy) on theclient computer 60 (process block 138).

  CLSID // root key {42754850-16b7-11ce-90eb-00aa003d7352} // GUIDsubkey   InProcServer32 = autprx32.dll // local (same machine) proxy;  NetworkAddress = 1.24.128.36 // remote IP address   ProtocolSequence =ncanc_ip_tcp // tcp/ip connect protocol

In addition, local OLE will use “1.24.128.36” as the network address ofthe remote computer 66 and TCP/IP as the network protocol to connect tothe remote computer. The Remote Procedure Call (RPC) facility is used toconnect to the remote computer 66. However, other facilities could alsobe used to connect the client computer 60 to a remote server computer66.

Windows® 95 and Windows NT™ provide RPC functionality via a RPC channelobject that encapsulates all the details about the underlyingcross-process and cross-network transport. The RPC channel object uses ageneric RPC transport provider interface to talk to a remote transportprotocol. The RPC provider interface acts as thin layer between the RPCfacility and the network transport, mapping RPC operations onto thefunctions provided by the network transport. The RPC facility implementstransport providers (e.g., DLLs) for named pipes, NetBIOS, TCP/IP,DECnet, and others. Additional transports can be supported by writingnew provider DLLs that plug into the RPC channel object.

Returning to FIG. 4, a connection is made to the remote computer usingthe Remote Procedure Call (RPC) facility, to create an RPC channel(process block 140), which is called a Remote Automation (RA) channel70. The RA Channel 70 connects the RA proxy 68 with a Remote AutomationObject Manager 72 running on the remote server computer 66. The RAObject Manager 72 is an object oriented application that is invoked byany client/server operating system supporting Remote Automation. The RAObject Manager 72 is capable of accepting a RPC channel connection froma remote computer, and spawning the necessary RA object orientedapplications to support remote object references.

The RA Object Manager 72 can be thought of as the agent or daemonequivalent in other distributed object systems such as ObjectBroker, byDigital Equipment Corporation, Orbix, by Iona Corporation, or PortableDistributed Objects, by NeXT Corporation. In these distributed systems(i.e., Digital's, Iona's, NeXT's), the agent resides on the serverplatform and serves to connect client requests to an appropriate serverimplementation and to return an object reference to the requestingclient. The RA Object Manger 72 performs the same service for requestingRemote Automation clients. However, the RA Object Manager 72 does notprovide the Common Object Request Broker Architecture (COBRA) basedObject Request Brokers, as the ObjectBroker, Orbix or NeXT products do.

Once the RA channel 70 has been established to the RA Object Manager 72(process block 142) the RA proxy 68 requests the RA Object Manger createa RA remote stub object oriented application 74 (hereinafter RA remotestub)(process block 144). As is shown in FIG. 5, The RA proxy 68 managesa facelet 76 for each object interface (e.g., there would be a faceletfor the object interface to object FOO). The RA remote stub 74 manages astublet 78 for each corresponding facelet managed by the RA proxy object(e.g., one stublet for FOO).

Object references 62 made from the client application go directly to theappropriate facelet 76 in the RA proxy 68, which marshals the referenceto the corresponding stublet 78 in the RA remote stub 74 through the RAchannel (RPC channel) 70. Marshalling is the ordering and packaging ofdata in a particular way to suit a particular network link and protocol,such as resolving local references, obtaining a copy of any local datastructures that a pointer refers to, byte swapping to conform to anotherCPU's data format, etc. When the appropriate stublet in the RA remotestub object 74 receives the marshalled reference, the stublet unmarshalsthe data and reconstructs the original reference. Marshalling is wellknown and understood by those skilled in the art.

Returning now to FIG. 4, the RA Object Manager 72 is just another clientobject oriented application, so OLE on the remote server computer 66(i.e., remote OLE) will create an OLE remote proxy object 80 within theRA Object Manager (process block 146), create the server application 82(process block 148), an OLE remote stub object 84 within the serverapplication 82 (process block 150), and an OLE channel 86 (process block152) which connects the OLE proxy object 80 and local stub object 84(see FIG. 2 and description above). After remote OLE does this creation,there is a two-way path between the client application 58 on the clientcomputer 60, and the server application 82 on the remote server computer66 (process block 154). Multiple two-way communications paths can beestablished between a client application on a client computer and aremote server application on a remote computer, or between a clientapplication and multiple remote server applications on one or moreremote server computers.

The path is two-way in the sense that a client object orientedapplication 58 can make a request for a remote object or remote objectdata and receive the remote object or the remote object data from theserver application 82. The client object oriented application 58 canmake object requests, and the server object oriented application 82responds to the requests. In an alternative embodiment of the presentinvention, the server object oriented application 82 can also makerequests from the client object oriented application 58.

The two-way communications path (process block 154) includes an objectlinking and embedding channel which is used to send object linking andembedding information (e.g., OLE information) to a remote computer,which is not possible with existing versions object linking andembedding software. The object linking and embedding channel allowsobject linking and embedding information to be sent from a local clientcomputer 60 to a remote server computer 66 with no manipulation of theobject linking and embedding data required by the applications andobjects shown in FIG. 4. The actual data pathway is transparent for bothlocal and remote OLE. Any data manipulation that may be necessary (e.g.,the marshalling and unmarshalling of data described above) to transportobject linking and embedding data on the object linking and embeddingchannel is also transparent to the applications and objects shown inFIG. 4.

Any remote object reference 62 now made from the client application 58to a remote object 64 from the server application 84 (process block156), goes to the RA proxy 68 (including the proper faceletmarshalling), through the RA channel 70 across the computer network, tothe RA remote stub 74 (including the proper stublet unmarshalling), tothe OLE remote proxy 80, through the OLE channel 86, to the OLE remotestub 84, and finally to the real object 64 on the remote serverapplication 84. Local OLE on the client computer 60 is not aware of theactual pathway shown in FIG. 4 to make the object reference. Remote OLEon the remote server computer also is not aware the object reference 62was made from the client computer 60, or the actual pathway to returnthe object reference.

In one embodiment of the present invention, an RA proxy/RA remote stubpair is created for each remote object reference. However, a single RAproxy/RA remote stub pair could be created in an alternative embodimentof the present invention to handle all remote object references.

The Remote Automation application ensures that objects are uniquelyrepresented and identifiable when passed from one computer to another byassigning every object a unique GUID when it is created. GUIDs wereexplained in detail above. The GUIDs generated are stored in a datastructure associated with the RA proxy on the client and in acorresponding data structure associated with all RA remote stubs tofacilitate lookup by GUID while passing remote object references. Thus,the client and remote server computers all understand and can identifyany remote object reference by looking up its GUID in their respectivedata structures.

Each time a remote object reference is passed to a remote servercomputer 66, a fast lookup on the object pointer using the stored GUIDsis performed using an operating system thread. This lookup iscomplicated because each operating system thread may contain a distinctobject pointer that references the same remote object. For example,thread A could contain a reference to object B with pointer A1, andthread B could contain a reference to object B with pointer B1.

In one embodiment of the present invention, a common operating systemthread called a “reference thread” is established to resolve allreferences to remote objects on the remote server computer. Every remoteobject reference 46 sent to the remote server computer 66 is passed tothe common reference thread which determines the location of the realobject 64, the OLE remote proxy object 80, and the RA stub object 74(the location of the OLE remote stub object 80 and OLE remote channel 86are determined from the location of the OLE remote proxy object 80). Thecommon reference thread eliminates the complicated object lookupdescribed above from multiple reference threads thereby increasing thespeed and efficiency of Remote Automation. The common reference threadcan also be used to resolve object references for local OLE automation(FIG. 3).

Security for object information passed over the object linking andembedding channel connecting a client 60 and remote server computer 66(i.e., inter-computer channels, including public Internet networkchannels) is also provided in Remote Automation. Data authentication,data encryption/decryption, and access control are used. However, moreor fewer security processes could also be used. One level of dataauthentication is provided in part by the RPC facility. RPCauthentication specifies the level of data integrity guaranteed betweenthe connected computers. As is known in the art, RPC offers seven levelsof authentication, ranging from “network default” to “packet privacy,”which includes data encryption for any data sent. Other dataencryption/decryption techniques could also be used on object referencedata before the data was sent to RPC (e.g., encrypted in the RA proxy,and decrypted in the RA remote stub).

Access control allows an administrator to specify which servers remoteclients may access. Access can be controlled down to the object classlevel. Remote Automation offers four levels of access control:CreateNone, CreateAll, CreateIfKey, CreateIfAcl. CreateNone does notallow any objects to be created, CreateAll allows any object to becreated, CreateIfKey allows an object to be created if the appropriateregistry key is set, and CreateIfAcl allows object creation only if anaccess control list for the class includes the client user.

Another level of security is also provided in the OLE environment (e.g.,on the local OLE channel that is the intra-computer OLE channels) viaobject oriented data abstractions. Data access is restricted to anexplicitly declared list of functions in an object class publicinterface. The protection of private object data (e.g., OLE channeldata) relies on the object oriented restriction on the use of publicclass member names.

In one embodiment of the present invention, the Remote Automationapplication is available in Visual Basic® 4.0, Enterprise Edition, byMicrosoft Corporation. A developer familiar with creating client/serverapplications in Visual Basic® which execute on a single computer can noweasily create distributed client/server applications using RemoteAutomation.

However, the Remote Automation application can also be used with otherobject oriented programming languages such as C++, Visual C++, andothers, and is not limited to the Visual Basic® language. Since RemoteAutomation is external to OLE, and extends OLE, Remote Automation canalso be made available as a stand alone external OLE application or anOLE add-on. In addition, the Remote Automation concepts discussed herecan also be directly incorporated in the COM or the DistributedComponent Object Model (DCOM) (i.e. the component object model fordistributed systems), which in turn could be directly incorporated intoOLE, instead of existing as an external object oriented applicationwhich hooks into OLE.

Remote Automation provides a set of interfaces to extend existing localOLE automation (FIG. 3) for use on distributed systems. Thus, RemoteAutomation inherits local OLE automation data limitations (e.g., localOLE automation cannot send data types such as structures through an OLEautomation channel). However, in an alternative embodiment of thepresent invention where Remote Automation is created as a stand-aloneobject oriented application which includes modifying the existing localOLE automation process (FIG. 3), the local OLE automation datalimitations are overcome (e.g., data types such as structures can besent through an OLE channel).

Remote Automation also provides the necessary building blocks for thedeployment of N-tiered client/server applications as is shown by method160 in FIG. 9. An N-tiered services model, for any type of client/serverservices, can be developed using Remote Automation. For example, athree-tiered client/server architecture is ideal for businessapplications. The three-tiered architecture provides the ability tosupport a conceptual layer of business logic between the traditionaltwo-tier components of the client user interface and a server database.The business logic layer can be maintained separately (e.g., on aseparate computer) from the data, which is not possible in thetwo-tiered client/server environment known in the art.

As is shown in FIG. 6, a logical three-tiered business architectureincludes a user services application 88 providing a user interface anduser interface navigation, that exists as a client application on aclient computer 90. The user services application uses Remote Automation92 (FIGS. 3 and 4) to communicate with a server business servicesapplication 94 on a remote second computer 96. The business servicesapplication 94 provides business policies/rules and generation ofbusiness information from data. The server business services application94, now acting as a client application, uses Remote Automation 92 tocommunicate with a server data services application 98 on a third remotecomputer 100. The data services application has access to a database102, and handles data definition, storage and retrieval of datarequested by the business services application. In the two-tieredclient/server model known in the art, the business services application94 and the data services application 98 would typically exist on thesame server computer, and consist of a complex set of object orientedapplications. This complex set of object oriented applications reside onthe same computer in the traditional two-tier client/server environmentsince remote object references are not available.

Remote Automation permits a physical N-layered business architecture tobe developed independently from the logical three-tier businessarchitecture (process block 162) shown in FIG. 6. For example, as isshown in FIG. 7A, a user services application 104 on a client computer106 uses Remote Automation 108 to communicate with several differentserver business services applications (110–114) on a remote secondcomputer 116. Each different business services application provides aspecific business functionality (e.g., one provides an account balance,two provides a record of sales, three provides a record of payments,etc.). Each of the different server business services applications,acting as client applications, uses Remote Automation 108 to communicatewith a data services application 118 on a remote third server computer120. The remote third computer is coupled to a database 122. FIG. 7Ashows a physical model with one layer in each of the three logical tierscorresponding to the three-tiered logical model shown in FIG. 6.

The business applications (110–114) may also exist on multiple remotebusiness computers (124–128) as is shown in FIG. 7B. There may also bemultiple data services applications (118,130) on multiple remote datacomputers (120,132) connected via Remote Automation in a variety ofconfigurations.

Remote Automation enables the physical performance and administrationneeds of a computer system (i.e., physical layering) to be fullyaddressed by allowing application objects to be located on one or moreremote computers as needs dictate (process block 164), without having togive up the code partitioning benefits of the logical model. Forexample, if a user interface application called several businessservices applications residing on one remote computer (e.g., FIG. 7A),and the performance of the one remote computer became unacceptable(process block 166), one or more of the business services applicationscould be moved to one or more additional remote computers (e.g., FIG.7B) to improve performance (process block 168). A similar scenario couldbe employed for the data services applications (e.g., FIG. 7B) includingadding additional computers/databases to the physical layout. Thephysical layering could be changed a number of times (process blocks166,168) without changing the logical model.

Changing the physical layering (e.g., FIG. 7B) has no effect on thelogical concepts developed for the three-tiered (or N-tiered) logicalmodel (e.g., FIG. 6). For example, FIG. 7B illustrates a six layerphysical model to provide functionality for the three-tiered logicalmodel shown in FIG. 6 (i.e., one physical layer for logical tier one(user services), three physical layers for logical tier two (businessservices), and two physical layers for logical tier three (dataservices)).

Remote Automation provides the ability to quickly and easily change andconfigure a physical model without affecting the original logical model.Any remote object references made by a client object orientedapplication are uniquely represented, and known to all server objectoriented applications, no matter how many physical layers are used torepresent a logical model.

Business applications on the remote business services computer would useRemote Automation to move some of the business service applications toone or more additional remote computers. The move would be invisible tothe user services interface application. When the user servicesinterface application made a reference to a business servicesapplication that was moved to a remote computer, the reference would bepassed to the proper place using Remote Automation. The remote computerwould know and understand the reference passed to it. Thus, RemoteAutomation provides substantial “invisible” physical flexibility once anN-tiered logical services model has been developed. The N-tiered logicalmodel made possible by Remote Automation is not limited to businessservices, but may be used to design a wide variety of otherapplications, requiring N-tiered layering.

Remote Automation is also used to provide the ability to referenceremote objects from a client network object oriented application (e.g.,an Internet client network application). Remote Automation provides theability to reference a remote object from a HyperText Markup Language(HTML) file. HTML is one of the standards for defining Internet networkdocuments. An object reference can now be added to an HTML file toprovide additional capabilities (e.g., multi-media capabilities) forHTML applications which formerly could only reference objects on thesame computer.

A Remote Automation object reference can also be used with, as, orwithin a Universal Resources Locator (URL) in a HTML file. A URL is astandard way specifying a site or page on a network (e.g., the Internetor world wide web). For example, a HTML reference to a remote object maybe:

  <OBJECT ID=MyObj “CLASSID=clsid:SF6E4ELO-9C38-11CF-  B63C-0080C792B782”>where “OBJECT ID=MyObj” is the name of an OLE object (e.g., MyObj) and“CLASSID=clsid:SF6E4ELO-9C38-11CF-B63C-0080C792B782” is the name and theASCII GUID value of the remote object.

Since hypertext transfer protocol (HTTP) and other protocols used withURLs for the Internet and other computer networks typically do notprovide any state information or object type checking, Remote Automationis used to provide state information and object type checking fornetwork client object oriented applications which need to access remoteobject information. Since Remote Automation uses RPC, which providesdata authentication, data encryption/decryption and access control,Remote Automation also provides the ability for a network client objectoriented application to use a secure, two-way communications path tocomplete a remote object reference without building in additionalsecurity features.

It should be understood that the programs, processes, and methodsdescribed herein are not related or limited to any particular type ofcomputer apparatus, unless indicated otherwise. Various types of generalpurpose or specialized computer apparatus may be used with or performoperations in accordance with the teachings described herein.

In view of the wide variety of embodiments to which the principles ofour invention can be applied, it should be understood that theillustrated embodiments are exemplary only, and should not be taken aslimiting the scope of our invention. Rather, we claim as our inventionall such embodiments as come within the scope and spirit of thefollowing claims and equivalents thereto.

We therefore claim as our invention all that comes within the scope andspirit of the following claims:

1. In a distributed computing system including a client computer havinga multi-tasking, threaded, operating system, and plural threads in aclient process sharing processor resources, the client computercommunicating with plural remote computers providing business servicesapplications on behalf of the client process, the computing systemhandling object references requested by said plural threads in theclient process, the client computer comprising: at least one processingunit and a memory; means for providing a common operating system threadto handle the runtime resolution of object reference requests; means forreceiving from a first thread running in the client process, a referencerequest for a first object providing business application services;means for determining by the common operating system thread, a firstremote computer providing access to the first object and establishing afirst communications channel with the first remote computer; means forreceiving from the first thread running in the client process, areference request for a second object providing business applicationservices; means for determining by the common operating system thread, asecond remote computer providing access to the second object andestablishing a second communications channel with the second remotecomputer; means for receiving from a second thread running in the clientprocess, a reference request for an object providing businessapplication services; means for determining by the common operatingsystem thread, that the reference requested by the second threadresolves to the first object; and means for providing businessapplications services to the client process via the establishedcommunications channels; wherein said business application servicesprovided to the client process comprise data received via theestablished communications channels and wherein said data received wasobtained by the business application services from one or moreadditional remote computers comprising data application services.
 2. Thecomputing system of claim 1 wherein the data received via theestablished communications channels is sent from the first and thesecond objects.
 3. The computing system of claim 2 wherein the first andsecond objects obtained the received data from plural of said additionalremote computers comprising data application services.
 4. A computingsystem for sending object information comprising: at least oneprocessing unit and a memory; means for providing a two-waycommunications path between a client object oriented application and aplurality of server object oriented applications residing on a pluralityof remote computers, the two-way communications path including an objectlinking and embedding channel; means for accepting an object referencefrom the client object oriented application to a remote object, whereinthe remote object reference is uniquely represented and identifiable byboth the client object oriented application and the plurality of serverobject oriented applications; means for passing the accepted remoteobject reference over the provided two-way communications path to aselected server object oriented application; and means for sending theremote object to the client object oriented application from theselected server object oriented application.
 5. The computing system ofclaim 4 where the object reference is an object linking and embeddingreference.
 6. The computing system of claim 4 where said two-waycommunications path is a secure communications path providing securityfeatures including access control, data authentication, and dataencryption/decryption.
 7. A computer readable medium having storedtherein instructions capable of causing the computing system to operateaccording to claim
 4. 8. A networked computing system for sending objectinformation, the networked computing system comprising: a first computerexecuting a client application; a first remote computer executing afirst server application, said client application requesting a servicefrom the first server application executing on the first remotecomputer; a plurality of second remote computers between said firstcomputer and said first remote computer, said plurality of second remotecomputers executing a plurality of second remote server applications;means for providing a two-way communications path between the clientapplication and the first remote server application through saidplurality of second remote server applications, the two-waycommunications path including an object linking and embedding channel;means for uniquely representing said request for service from the clientapplication to the first remote server application, and to the pluralityof second remote server applications; means for passing said request forservice from the client application, through the plurality of secondremote server applications, to the first remote server application usingsaid two-way communications path.
 9. The computing system of claim 8where the request for service is a request for service from a remoteobject.
 10. The computing system of claim 8 where the request forservice is an object linking and embedding service request.
 11. Anetworked computing system for sending object information, comprising: acomputer executing a network client object oriented application; aplurality of remote computers having a plurality of network serverobject oriented applications residing thereon; means for providing atwo-way communications path between the network client object orientedapplication and the plurality of network server object orientedapplications residing on the plurality of remote computers, the two-waycommunications path including an object linking and embedding channel;means for accepting an object reference to a remote object fromhypertext markup language data on the network client object orientedapplication, where the object reference is uniquely represented andidentifiable by the network client object oriented application and theplurality of network server object oriented applications; means forpassing the accepted remote object reference over the provided two-waycommunications path to a selected server object oriented application;and means for sending the remote object to the client object orientedapplication from the selected server object oriented application. 12.The computing system of claim 11 where said object reference is includedin a universal resource locator within said hypertext markup languagedata.
 13. The computing system of claim 11 where the object reference isan object linking and embedding reference.
 14. The computing system ofclaim 11 where said two-way communications path is a securecommunications path, providing security features including accesscontrol, data authentication, and data encryption/decryption.
 15. Acomputer readable medium having stored therein instructions capable ofcausing the computing system to perform according to claim
 11. 16. Anetworked computing system for maintaining object reference identitywhen an object reference is passed between the first and remote secondcomputers, the networked computing system comprising: a first computerand a remote second computer, each computer having a central processingunit coupled to a memory, and a client/server operating system; meansfor modifying a registry database maintained on the first computer, themodifications including instructions for communicating with a remoteserver object oriented application residing on the second remotecomputer; means for making a reference from a client object orientedapplication running on the first computer to the remote server objectoriented application; upon detection of said reference, means for usingthe instructions from said modified database registry to initiate on thefirst computer a proxy object oriented application, and establish afirst two-way communications channel between said proxy object orientedapplication and a remote automation object manager running on the remotesecond computer; means for requesting said remote automation objectmanager to initiate a remote stub object oriented application; means forrequesting said remote stub object oriented application to initiate aremote proxy object oriented application; means for requesting saidremote proxy object oriented application initiate a remote server stubobject oriented application; means for requesting said remote proxyobject oriented application to establish a second two-way communicationschannel between said remote proxy object oriented application and saidremote server stub object oriented application; means for establishing atwo-way communications path between the client object orientedapplication and the remote server object oriented application using saidproxy, remote stub, remote proxy, and remote server stub object orientedapplications and said first and second two-way communications channels;and means for passing said reference from the client object orientedapplication on the first computer to the remote server object orientedapplication on the second computer using said two-way communicationspath.
 17. The networked computing system of claim 16 further comprising:means for passing said reference from said client object orientedapplication, to said proxy object oriented application, to said remotestub object oriented application, to said remote proxy object orientedapplication, to said remote server stub object oriented application, tosaid remote server object oriented application using said two-waycommunications path; and means for maintaining the ability to identifysaid reference at each of said object oriented applications throughwhich said reference is passed in said two-way communications path. 18.The networked computing system of claim 16 where the requesting saidremote proxy object oriented application to initiate a remote serverstub object oriented application includes requesting the remote proxyobject oriented application to initiate the remote server objectoriented application, the remote server object oriented applicationincluding a remote server stub object oriented application.
 19. Thenetworked computing system of claim 16 where the two-way communicationspath includes a two-way object linking and embedding channel.
 20. Thenetworked computing system of claim 16 where the reference is an objectlinking and embedding reference.